Pursuant to 35 U.S.C. xc2xa7 119(a), this application claims the benefit of the filing date of Japanese patent application no. 11-274,036, filed on Sep. 28, 1999.
1. Technical Field
The present invention relates to a disk apparatus such as a hard disk drive (HDD) and a control method therefor. In particular, the present invention relates to a disk apparatus having a command queue that holds a plurality of commands transmitted from one or more external apparatuses, such as a host apparatus, in which the disk apparatus utilizes rotational position optimization (RPO) to select a command to be next executed, and to a control method for such a disk apparatus.
2. Description of the Related Art
Some disk apparatuses each comprise a command queue holding a plurality of commands. Command processing in such a disk apparatus includes queuing a command received from a host apparatus into the command queue, selecting a command to be next executed from among a plurality of execution-waiting commands in the command queue, and executing the selected command. The command to be next executed may be selected with RPO, for example.
RPO is a method of estimating seek time and latency time for each command in the command queue (where seek time is the time from starting a seek of a target track to the completion of positioning a head on the target track and latency time is disk rotation time from the completion of the head positioning to the start of accessing a target sector) and selecting the execution-waiting command having the shortest seek/latency time (i.e., seek time plus latency time) as the command to be next executed. Thus, RPO is a method for selecting, as the command to be next executed, the execution-waiting command that can access the target sector on the disk in the shortest time. To utilize RPO to select the command to be next executed is also called to xe2x80x9csort with RPO.xe2x80x9d
A micro program for performing the above-described command processing may include a queue handler that selects a command to be next executed from the command queue, a command handler that executes the selected command, an interface (I/F) event handler that monitors extra-drive processing (processing relating to data transfer) and that queues (stores in a queue) a command transmitted from the host apparatus, and a drive event handler that monitors intra-drive processing (processing relating to a disk access). In addition, the disk apparatus contains drive means (hardware) that drives an access mechanism and executes the intra-drive processing, and I/F means (hardware) that executes the extra-drive processing.
In addition, in conventional command s processing, if an error arises in the intra-drive processing while a command is being executed (if an error relating to a disk access arises), a retry is started and continued until an error is resolved, and a next command is executed after completing the execution of the command that generated the error. Therefore, if an error arises, the retry is performed to again access a target sector on a disk after waiting one rotation time of the disk.
FIG. 13 is a flow chart illustrating a control routine of a conventional command handler.
First, in step ST31, the command handler not only initializes the drive means and I/F means, but also transmits a parameter for command execution to the drive means and I/F means to activate the drive means and I/F means.
Next, in step ST32, the command handler judges whether an I/F event is present. If the I/F event is present in step ST32, the command handler handles the I/F event in step ST33: to go to step ST34. In addition, if the I/F event is not present in step ST32, the command handler skips step ST33 to go to step ST34.
The above-described I/F event is an event generated according to the operation of the I/F means by the I/F event handler. In addition, the I/F event processing in step ST33 is the processing of controlling the I/F means or drive means for according to the contents of the I/F event.
In step ST34, the command handler judges whether a drive event is present. If the drive event is present in step ST34, the command handler handles the drive event in step ST35 to go to step ST36. However, if the drive event is not present in step ST34, the command handler skips step ST35 to go to step ST36.
The above-described drive event is an event generated according to the operation of the drive means by the drive event handler. In addition, the drive event processing in step ST35 is the processing of controlling the drive means and/or I/F means according to the contents of the drive event.
In step ST36, the command handler judges whether the I/F event processing and drive event processing are entirely completed. If not completed, the command handler returns to the step ST32. In this manner, the command handler executes commands through a loop of steps ST32 to ST36. Then, if the intra-drive processing and extra-drive processing are entirely completed in step ST36, the command handler completes the execution of the command.
FIG. 14 illustrates a timeline for conventional command processing. FIG. 14 shows a case in which a command CMD1 is successfully executed, an error then arises in intra-drive processing (processing relating to a disk access) during the execution of a next command CMD2, and the execution of the command CMD2 is retried.
When the intra-drive processing of the command CMD1 is completed, the drive event handler 24 generates a DCOMP event (drive event) informing the command handler of the completion of the intra-drive processing, and informs the command handler of it. The command handler handles the DCOMP event (DCOMP processing), and completes the execution of the command CMD1.
During the execution of the command CMD1, a queue handler sorts commands that are stored in a command queue with RPO and selects a command CMD2 as a next command to be executed after the command CMD1. When the command handler completes the execution of the command CMD1, the queue handler transmits the command CMD2, which will be next executed, to the command handler to request the execution of the command CMD2 (KICK NEXT).
The command handler starts the execution of the command CMD2, performs the initialization as described in step ST31 shown in FIG. 13, drives the access mechanism by the drive means, and makes a seek of a target track started (KICK SEEK). Then, according to the loop of steps ST32 to ST36 that is shown in FIG. 13, the command handler advances the intra-drive processing of the command CMD2.
In addition, when the I/F means receives a new command from the host apparatus, the I/F event handler queues this command in the command queue (NEW CMD, ENQUE). The queue handler sorts a plurality of execution-waiting commands including the above-described new command with RPO (RPO SORT) and selects a command that will be executed after the command CMD2.
If an error relating to a disk access arises during the execution of the command CMD2, the drive event handler generates an error incidence event (drive event) to transmit this error incidence event to the command handler.
When the command handler recognizes the error incidence event, the command handler increments a step of an Error Recovery Procedure (ERP) to make a retry started in the drive event processing in step ST35 shown in FIG. 13. Owing to this, the access mechanism again accesses the target sector after waiting one rotation of the disk.
In a disk access, a disk apparatus not only changes a retry procedure from a first disk access procedure to a retry procedure due to an error, but also changes the retry procedure according to the number of retries, and these procedures are called ERP. In the ERP having m steps, a disk access is tried at step 0 of the ERP, and if an error arises, another disk access is tried at step 1 of the ERP. Subsequently, disk accesses are sequentially tried at steps 2 to (m-1) of the ERP, and if an error arises at step m of the ERP, the disk apparatus informs a host apparatus of a hardware error (an error relating to a disk access) arising.
If a retry completes the access without error and the intra-drive processing of the command CMD2 is completed, the drive event handler generates a DCOMP event to transmit the DCOMP event to the command handler 22. The command handler 22 handles the DCOMP event (DCOMP processing) to complete the execution of the command CMD2.
In this manner, in conventional command processing, if an error arises, the command handler starts a retry, and the disk apparatus again accesses a target sector where the error arose, after waiting one rotation of the disk.
Thus, in the above-described conventional command processing, if an error relating to a disk access arises, the disk apparatus again accesses the disk after waiting one rotation of the disk. Therefore, command execution time becomes longer by the time necessary for one rotation of the disk each time a retry is performed due to error incidence, and hence the command execution time uselessly increases every rotation time of the disk.
In addition, RPO is a method for estimating seek time and latency time when each command in the command queue is executed and for selecting a command that can access its target sector in the shortest time as the command to be next executed. However, an actual disk apparatus has a dispersion of seek times. For this reason, in conventional command processing, if seek time exceeds the time estimated with RPO, it is not possible to start the access to the target sector if the disk apparatus does not wait one rotation of the disk, and hence the time corresponding to one disk rotation is consumed.
The present invention is performed in consideration of such conventional subjects, and is to increase the efficiency of command processing by decreasing the disk latency time at the time of command execution.
In a method according to the present invention for controlling a disk apparatus having an interface, command storage, and data storage, one or more commands are received from an external apparatus via the interface, and the one or more commands are held in the command storage. A command to be next executed is selected from among the one or more commands and dispatched for execution. It is determined whether an error relating to accessing the data storage has arisen during execution of the selected command. If so, the selected command is restored to the command storage. A subsequent command to be next executed may then be selected. In one described embodiment, an estimated seek time for the selected command is determined, and it is judged that an error has arisen if actual seek time of the selected command exceeds the estimated seek time.
All objects, features, and advantages of the present invention will become apparent in the following detailed written description.